Selerix Developer Tools
Man-in-the-Middle Attacks

How a Man-in-the-Middle Attack Occurs

A man-in-the-middle attack exploits some vulnerability of a network or network protocols, such as Address Resolution Protocol (ARP), to insert the attacking system between a computer and the server or router it is trying to connect to.

Basically, the attacking computer pretends to be the user or requesting computer during communications with the server or router and pretends to be the server or router during communications with the user or requesting computer. All the while, the attacking computer can record the potentially sensitive information being passed between the two.

Some sort of spoofing attack, such as ARP Poisoning, is used to insert the attacking computer into the conversation. ARP poisoning and other spoofing attacks are discussed at length on both security and hacking web sites, should you need additional information.

After the attacking system has inserted itself into the conversation, it invisibly examine data and determine what to send to and from the user and the web site.

NOTE: For ease of identification, the user (good guy) wears a white hat and the attacker (bad guy) wears a black hat in the following diagrams.

 

Because the Site does not recognize that it is being fooled, it responds to the request and that response is passed to the attacker.

The attacker passes the response to the user, who is also unaware that he is being fooled.

 

 

 

 

The user's system, thinking everything is normal, sends unencrypted login and password information. The attacker now has the key to the site and can perform any activity that the user has permission to perform.

How to Avoid a Man-in-the-Middle Attack

The Man-in-the-Middle attack is one of the most difficult attacks to completely defend against, but it is possible to defend against most attacks by encrypting the login and password when the user sends them.

Because SAML 2.0 supports XML encryption, it is somewhat less vulnerable to man-in-the-middle attacks than SAML 1.1.

NOTE: For ease of identification, the user (good guy) wears a white hat and the attacker (bad guy) wears a black hat in the following diagrams.

 

 

 

 

 

 

 

 

Making SAML 1.1 Secure

SAML 1.1's vulnerability to this sort of attack, combined with the sensitive nature of the data being transmitted, have lead to Selerix requiring that all census data must either be transmitted in a separate, more secure transaction or be pre-loaded into the Selerix database.

The ability to safely transmit data not only increases security, it also makes loading census data much easier and efficient because you are never required to expend time and effort collecting census data to transmit it to Selerix.